.. to make sure that the new migration timestamp you are working on will still be applied when another collaborator may have created and merged a migration before you.

This is interesting. Is this a workaround to force goose to apply migrations that may be out-of-order when using timestamps and/or sequences?

If so, I'd much rather see a strict mode with the option to disable it as described in this thread #172 .. which would allow the behaviour mentioned here #172 (comment)

.. to make sure that the new migration timestamp you are working on will still be applied when another collaborator may have created and merged a migration before you.

This is interesting. Is this a workaround to force goose to apply migrations that may be out-of-order when using timestamps and/or sequences?

If so, I'd much rather see a strict mode with the option to disable it as described in this thread #172 .. which would allow the behaviour mentioned here #172 (comment)

No that is not the intention of this flag. This flag is intended to be able to quickly return the last N number of migrations for a database when running the status command.

There are 2 reasons that I find this helpful.

The first is when I am checking if an environment has had the latest migrations applied I don't want to see the full list of migrations just the last 5-10 to make sure that the migrations are applied not pending.

The second use case that I find it useful is because my team creates migrations for stories and this is all happening asynchronously and one story that is started first might take longer than another that finishes faster. Then at this point the timestamp of the migration that was created first would be out of sync and would not get applied if the date isn't updated.

With my current project we have hundreds of migrations and it takes quite a long time for goose to print out all the migrations when using that status command just to see if the order of the migration you are trying to add is correct. This second scenario could also be solved by just looking at the file names but it could be a lot easier to just run the status command if only the last few migrations are printed.

My issue with this PR is that it modifies the resulting migrations list in CollectMigrations. And so this doesn't only affect status command, but all other commands.

If you'd like to print last-n migrations we can likely accomplish this with another implementation specific for status.

As mentioned in #256 (comment), I'd rather properly add opt-in disable strict mode to address things like this:

.. to make sure that the new migration timestamp you are working on will still be applied when another collaborator may have created and merged a migration before you.